浅谈敏捷开发及Scrum（三）工具leangoo

最新推荐文章于 2019-05-24 18:07:24 发布

IT-老五

最新推荐文章于 2019-05-24 18:07:24 发布

阅读量505

点赞数

分类专栏：随笔工具&方法

本文链接：https://blog.csdn.net/andy_5826_liu/article/details/88889359

版权

随笔同时被 2 个专栏收录

11 篇文章 0 订阅

订阅专栏

工具&方法

6 篇文章 0 订阅

订阅专栏

之前两篇有说到敏捷开发及Scrum的一些概念及实施，现在再来记录下我们在敏捷开发实施中使用的一些工具，主要说下leangoo和zendao。

工具不是敏捷开发及Scrum的必须品，但有了工具，可以让敏捷开发更好的实施。

因为篇幅及时间问题，这里先说下leangoo：

关于leangoo，我想讲的主要有三张图，PO的Product Backlog、Team的Sprint Backlog及Sprint的燃尽图。

Product Backlog

以下是我们PO使用的Product Backlog，基本与leangoo的示例一致，这个示例也是满足软件开发过程的。

PO-Product Backlog.jpg

这是一张PO的Product Backlog（如果看不清，可以放大），需要注意的都已经用红色标注：

1. 待梳理需求

PO从用户（包含领导、客户、自己）得到的需求，肯定是不完善的，大多都是需要做一个什么功能之类的“一句话需求”，对开发团队而言，这些都是不可执行的；但是PO可能也不能及时进行梳理，所以先把这种“一句话需求”放入该列记录起来。

2. 以后的Sprint

这些都是PO已经梳理了，可执行的需求，我们称之为Story（故事），一般这一列都是紧急度不是非常高，但是在后续需要做的。从这一列起，任务是带有时间点数的，这里一般是PO估算的大概点数，与迭代中团队估计的点数可能有差别，但是随着团队的默契度上升，这个点数应该能与团队评估点数越来越接近。

3. 下个Sprint

这些一般来自于“以后的Sprint”一列，是可执行的，而且紧急度较高的（紧急度由PO根据需求来源、商业价值、工作量等因素进行确定），而且这一列的Story都应该是紧急度排好序的，越往上越紧急。PO大概评估，这一列的Story点数一般略高于团队能完成的点数。这一列的Story需要PO在当前迭代开始准备，在迭代结束前整理好，这样才能让迭代不会中断。

4. 当前Sprint

这一列是当前迭代进行的Story，原则上是不允许替换的，除非是特别紧急的任务。这一列开始，Story的任务点数可以换为与团队评估的时间点数一致。

5. 已交付

这一列是已经交付的Story，是一些已经通过PO验收，已经上线或者随时可以上线的Story。

leangoo上主要的两张Backlog，PO一个人就需要维护一张，可见，在Scrum迭代中，PO处于一个能决定迭代成败的绝对核心位置，PO的任务及责任都是非常重的。

Team的Sprint Backlog

下图是我们团队的Sprint Backlog，这个需要整个团队都主动去维护，每天完成的Task和Story都主动去拖动。

Team-Sprint Backlog.png

这个Backlog我们与示例一些差别，我们分为了六列，这样更适用于软件开发，这哥Backlog一般在迭代的第一天（迭代启动会后）生成：

1. Story

这个很好理解，迭代中需要完成的故事，在故事都是标记好点数，标记好晚上时间，并标记好负责人的，而且每一个Story都应当有检验项供测试及PO验收。

2. Task

对应的Story拆分为可以执行的且短时间内可完成的小任务，每一个Task都有完成时间和负责人，这些Task都是待执行的状态。

3. Task-doing

Task的执行当天，负责人将该Task从Task列拖到Task-doing列，表示该Task正在处理。

4. Task-done

Task完成后，由负责人将Task拖入该列。

5. Story-testing

当该Story对应的所有Task都完成后，将该Story拖入Story-testing列，测试人员开始进行测试工作。

6. Story-done

当测试人员完成测试后，将Story拖入该列，表示该Story已经顺利完成。

一个迭代会有很多的Story，我们每个开发人员都会建立一个泳道，然后将自己的Story拖入泳道中（也有的团队是每个Story一个独立的泳道，这个看自己的需求情况而定）；在Task及Story完成后，团队成员需要主动、及时的拖动Task和Story，不然对应Task或Story会变为红色，而且整个Sprint对应的燃尽图会变得很怪异；在迭代的第一天，应该讲Story拆分为Task，并且Story完成时间不能标记到迭代的最后一天（最后一天应该是产品验收会及迭代总结会），开发Task完成时间不能标记到迭代的最后两天（给测试预留时间，并且需要进行回归测试）；在迭代正式开始后，Story和Task应该是不变的，不然很难保证迭代的顺利进行；